1. Statement of the Technical Field
The present invention relates to the field of servlet deployment and more particularly to servlet configuration in an application server.
2. Description of the Related Art
Servlets are programs that extend content servers by providing a component-based method for building content-based applications. In particular, an application server can incorporate servlets in combination with markup and other resources to form a Web application. More recently, Web applications have been packaged for deployment using archive tools and deployed across multiple differing containers. For instance, version 2.2 of the Java™ Servlet Application Programming Interface (API) provides for a Web archive (WAR) file which includes the bundling of servlets, hypertext markup language pages, Java classes and other resources.
From an application server perspective, servlets can be deployed alone or within an archive. In both circumstances, however, the application server must have an awareness of particular run-time characteristics of the servlet, for example context initialization parameters, session configuration information, markup tag definitions and mappings to the servlet and its respective encapsulated members, MIME type mappings, a welcome file list, error pages and security data. Additionally, the servlets must be made available to the application server through a specified file system search path. For instance, where a servlet implements the Java Servlet API, a corresponding application server will be able to access the servlet only through a file system search path specified by the classpath environment variable.
Application server administrators typically define servlets in two ways. In the first case, the application server administrator can define the servlet to the application server as an explicit server resource belonging to a particular application. For example, the application server administrator can explicitly configure the application server with a servlet resource for each servlet class file. Notably, in conventional application servers, the explicit configuration of a servlet is performed individually for each servlet defined in a deployed application.
In any case, during the development phase of a Web application to be deployed in an application server, the number and characteristic of individual servlets for which the Web application can be configured and the respective names of those servlets can change continuously. In consequence, in addition to the explicit configuration of a servlet, conventional application servers can be configured implicitly. In particular, an implicit configuration of the application server can permit the application server to invoke any servlet residing in a specified file system search path. The implicit configuration of servlets can be accomplished by adding an “invoker servlet” to the Web application, as is well-known in the art. Importantly, it is efficient to use an implicit configuration during application development because, as new servlets are added to the application, or as existing servlets change, no modifications are necessary to the application server configuration for development testing.
Nevertheless, when deploying a Web application, implicit servlet configuration no longer remains an efficient strategy. Specifically, there are disadvantages to enabling serving servlets implicitly by reference to file system search path, rather than explicitly by reference to the servlet itself. First, an explicitly configured servlet can be monitored individually, but an implicitly configured servlet cannot be monitored individually. Thus, if an application administrator requires servlet performance statistics such as requests and execution time, then those servlets must be explicitly configured.
Second, the use of an implicit invoker servlet presents security issues. In particular, when a Web application permits end users to invoke servlets that are implicitly defined, then users can access any servlets defined in the file system search path of the Web application. In consequence, it is not possible to limit access to servlets that are on the classpath. Once the application server has been configured to permit the implicit invocation of servlets, any servlet function that resides in specified file system search path can be invoked by the application users. Notably, many conventional application servers implement security based upon defining and securing individual servlet resources.
Ordinarily, a servlet can be explicitly configured in an application server through the manual navigation of a servlet configuration module. For instance, typically the application server administrator can enter an administration console of the application server through which the administrator can specify a servlet, an application server, a servlet engine, and Web application. Subsequently, the administrator can select an explicit servlet configuration menu option in the console. As one skilled in the art will recall, this manual process must be repeated for each servlet defined in the Web application to be deployed.
Recently, application servers have included servlet deployment tools which automate the heretofore manual configuration process. In particular, the servlet configuration information can be included in a document which can be provided to the application server in lieu of an administrator manually configuring the application server for each servlet. In the WebSphere™ application server, manufactured by International Business Machines Corporation of Armonk, N.Y., for example, an “XMLConfig” tool can be used to produce extensible markup language (XML) formatted configuration files. Nevertheless, the configuration still must be manually specified in the configuration file. Hence, the production of a configuration file still requires much tedium and effort.